Есть пара интересных постов, на базе которых мы попробуем вкратце описать поведение кластера VMware Virtual SAN в случае, если при развертывании виртуальной машины кластер не способен обеспечить требуемые политики хранилищ (Storage Policies).
1. Обычный кластер Virtual SAN.
Если при развертывании новой ВМ в кластере VSAN невозможно обеспечить требуемые политики хранилищ (например, не хватает места для создания зеркалируемых объектов реплик), а именно:
то виртуальная машина не сможет быть развернута в кластере. Но есть такая настройка Force Provisioning для VM Storage Policy, которая позволяет игнорировать указанные 3 параметра при развертывании новой ВМ в кластере.
Однако надо понимать, что при использовании Force Provisioning происходит не понижение требований кластера к хранилищу виртуальной машины (например, вместо FTT=2 можно было бы проверить FTT=1), а использование следующих параметров:
NumberOfFailuresToTolerate = 0
NumberOfDiskStripesPerObject = 1
FlashReadCacheReservation = 0
То есть нужно просто аллоцировать место под виртуальную машину, совершенно без соблюдения требований к дублированию данных и резервированию кэша.
Но кластер Virtual SAN имеет еще одну специфическую черту - если вы использовали Force Provisioning при недостатке дисковых ресурсов, то когда они освободятся, для хранилища машины будут сделаны реплики дисковых объектов и прочие операции, чтобы она все-таки соответствовала требуемым политикам хранилищ. Администраторам надо иметь эту особенность в виду.
И еще один момент - так как в случае Force Provisioning может храниться только одна копия дисковых объектов, то, например, если при переводе хоста в режим Maintenance Mode случится какой-нибудь сбой с его хранилищем - реально можно потерять эту машину целиком. Делайте бэкап и, по-возможности, не используйте Force Provisioning - старайтесь соблюдать политики хранилищ хотя бы на уровне FTT=1.
2. Растянутый кластер (Stretched Cluster).
В случае растянутого кластера появляется еще один компонент - Witness Appliance, следящий за ситуацией Split Brain, которая может появиться между площадками. Если вырубить этот виртуальный модуль и попытаться включить виртуальную машину или создать новую ВМ, то кластер Virtual SAN (несмотря на то, что он Failed и политика хранилищ не соблюдена) позволит это сделать, правда будет ругаться, что машина не соответствует текущим политикам хранилищ:
В остальном растянутый кластер ведет себя по отношению к Force Provisioning так же, как и обычный.
платформой vSphere - HTML5 Web Client 1.1. Эта версия заменит собой текущий Web Client, который сейчас работает на основе тормозной технологии Adobe Flex.
Оказывается в HTML5 Web Client есть три скрытых возможности, о которых написал Emad Younis, и которые, видимо, еще находятся не в очень стабильном состоянии, поэтому разработчики решили отключить их. Но так как вы используете новый клиент только в целях тестирования - то давайте включим их и посмотрим, что это за фичи.
1. Итак, заходим на vSphere HTML5 Web Client Fling Appliance по SSH.
2. Переходим в папку /etc/vmware/vsphere-client/vsphereFeatures:
# cd /etc/vmware/vsphere-client/vsphereFeatures
3. Находим там файл vsphereFeatures.cfg и открываем его для редактирования в редакторе vi:
# vi vsphereFeatures.cfg
4. Видим там, что некоторые 3 фичи настроены в состояниях disabled. Это:
Datastore File Browser
Add Host Wizard
Network Selector
5. Включим какую-нибудь из них, например, файловый браузер:
6. Перезапустим веб-службы Web Client следующей командой:
# /etc/init.d/vsphere-client restart
7. Теперь зайдем в консоль веб-клиента по адресу:
https://<имя или IP модуля>:9443/ui
И перейдем в раздел Datastore –> Manage –> Files, там мы и увидим файловый браузер:
8. Теперь запустим Add Host Wizard для добавления нового хост-сервера VMware ESXi в кластер:
И попробуем добавить новый хост:
9. Ну а расширенный выбор VM Network находится в настройках виртуальной машины VM –> Network Adapter –> Network drop down –> Show more networks:
Скорее всего, эти 3 фичи появятся в следующей версии HTML5 Web Client, а ждать ее осталось недолго. Но ведь и там будет файлик vsphereFeatures.cfg, в котором можно будет взглянуть на следующие новые возможности нового поколения тонкого клиента VMware vSphere.
Таги: VMware, Web Client, Update, vSphere, ESXi, Обучение, Blogs
Как многие из вас знают, VMware довольно-таки неплохо развивает интерфейсы и технологии для обеспечения возможности разработки сторонних средств по управлению виртуальной инфраструктурой (обратите внимание, например, на Ruby vSphere Console). Кроме того, компания уделяет немало внимания и сообществу независимых разработчиков. В рамках этой активности VMware на днях запустила веб-сайт VMware {code}, на котором собраны ресурсы для всех тех, кто занимается разработкой ПО для лидирующей платформы виртуализации.
Многим из вас темы опубликованных на ресурсе статей покажутся непонятными и мутными, но для тех, кто в теме, это отличный образовательный ресурс и способ поддержания своих знаний "up-to-date".
В разделе VMware on GitHub можно найти открытые репозитории некоторых проектов VMware на GitHub, например, Photon:
В разделе "Learn" есть подразделы о DevOps, Cloud Native Apps, vRealize Code Stream и прочие, а также лабораторные работы для разработчиков (Hands on Labs):
Известный многим из вас блоггер Фрэнк Деннеман (Frank Denneman) на днях анонсировал третье издание книги о проектировании виртуальной инфраструктуры VMware - vSphere Design Pocketbook v3, которая построена на базе материалов авторов, пишущих о виртуализации в своих блогах или на других ресурсах:
Книга представляет собой сборник статей известных блоггеров и специалистов в области построения виртуальной инфраструктуры, которые широко известны в медиа-пространстве. Среди них такие известные ребята, как William Lam, Matt Leibowitz, Frank Denneman и другие.
Книга доступна бесплатно в электронном виде по этой ссылке, а в печатном виде будет распространяться на конференции EMC World. В книге 157 страниц рекомендаций по дизайну инфраструктуры виртуализации в формате блог-записей, в которых авторы стараются быть максимально конкретными и пишут по сути (со скриншотами, графиками и таблицами).
Ниже содержание книги с указанием авторов соответствующих статей, которые объединены в 7 глав, отражающих основные аспекты проектирования виртуальной инфраструктуры VMware vSphere:
Chapter 1 – Host Configuration
Host Design – Scale-Up or Scale-Out? (by Rene van den Bedem)
VMware ESXi – Async Drivers (by Patrick Schulz)
Don’t Forget the Logs (by Steve Wood)
Chapter 2 – Cluster and vCenter Design
VMware Resource Pools (by Eric Shanks)
Tweet Sized Design Recommendation (by Doug Baer)
vCenter is Down – Impact on VMware Infrastructure (by Mariusz Kaczorek)
Tweet Sized Design Recommendation (by Amit Rathod)
Enhanced vMotion Compatibility (EVC) Best Practices (by Dee Abson)
What Does Load Balancing the Platform Services Controller Really Give You? (by William Lam)
Chapter 3 – Storage Configuration
The Ultimate IOPS Cheat Sheet (by Bas van Kaam)
Tweet Sized Design Recommendation (by Doug Behr)
Determine Your vSphere Storage Needs (by Michael Wilmsen)
Tweet Sized Design Recommendation (by Patrick Schulz)
vSphere Replication – Consider These Points Before Using It (by Craig Kilborn)
Know the Minions by Chethan Kumar
Understanding Block Sizes in a Virtualized Environment (by Pete Koehler)
Chapter 4 – Network and Security Design
vSphere 6.0 – Configure VMware Certificate Authority As A Subordinate CA (by Kyle Jenner)
Те из вас, кто уже давно администрирует платформу VMware vSphere, знает о такой штуке RVTools, которая помогает в выполнении многих административных задач. О прошлой версии RVTools 3.7 мы писали где-то год назад, а совсем недавно вышел очередной апдейт утилиты - RVTools 3.8.
Давайте вкратце посмотрим на новые возможности RVTools 3.8 (полный их список доступен тут):
число поддерживаемых мониторов и видеопамяти в килобайтах
статус конфигурации (конкретные проблемы с конфигом видны на вкладке vHealth)
операционная система (то, что дает VMware Tools)
Новые поля на вкладке vTools:
App state, App heartbeat и статус Kernel crash
Доступность операций: поддержка изменения статуса и доступность интерактивных операций с гостевой ОС
На вкладке vHost появился статус NTPD.
Проблемы с NTP теперь видны на вкладке vHealth.
Новое поле Config status добавлено на вкладках vHost, vCluster и vDatastore
На вкладке vSC+VMK добавлены поля IP 6 Address и IP 6 Gateway.
Все вкладки, относящиеся к виртуальным машинам, теперь имеют колонки VM Object ID, VM UUID, powerstate и template. Колонки Custom Attributes упорядочены по алфавиту.
На всех вкладках появилась колонка vCenter UUID.
Множество исправлений ошибок.
Скачать RVTools 3.8 можно по этой ссылке. Документация доступна тут.
В недавно вышедшем обновлении платформы виртуализации VMware vSphere 6.0 Update 2 появилась возможность конфигурации Logon Banner (он же Security Banner) для того, чтобы предупредить пользователей или потенциальных злоумышленников о последствиях неавторизованного доступа к системе. Подробно об особенностях его конфигурации написал Вильям Лам, а мы рассмотрим тут основные моменты настройки баннера вкратце.
Это стандартный подход к обеспечению безопасности, баннер мало кого останавливает, но хотя бы сам факт его наличия будет еще одним пунктиком при привлечении нарушителя к ответственности.
Конфигурация логон-баннера доступна только через интерфейс Platform Services Controller (PSC) Administrator UI, к которому можно получить доступ по следующей ссылке:
https://[PSC-HOSTNAME]/psc
В разделе Configuration вы найдете конфигурацию баннера, где можно настроить следующие параметры:
Status - включен он или выключен.
Checkbox Consent - будет ли показан обязательный для отметки чекбокс согласия с правилами.
Title - заголовок текста.
Message - собственно, само сообщение.
Также можно изменять данные параметры из командной строки с помощью сценария /opt/vmware/bin/sso-config.sh, что требует SSH-доступа к хосту PSC. Ну и вам понадобится создать файл banner.txt, где будет содержаться основной текст баннера безопасности.
Для того, чтобы установить заголовок баннера и его текст, но не включать чекбокс, используйте следующую команду:
opt/vmware/bin/sso-config.sh -set_logon_banner /root/banner.txt -title 'Disclaimer' -enable_checkbox N
Можно не использовать путь к тестовому файлу, а, например, просто изменить заголовок:
Тем из вас, кто администрирует инфраструктуру Microsoft, может оказаться интересным технологический блог компании StarWind Software, которая производит лучшее средство для создания отказоустойчивых хранилищ для инфраструктуры Hyper-V - Virtual SAN.
В своем блоге сотрудники компании рассказывают об интересных фишках, например, есть посты от основателя и CTO компании Антона Коломейцева о том, как сделать бесплатный SMB 3.0 сервер на бесплатном Hyper-V Server, да еще и в кластерной конфигурации:
Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.
Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:
Очередная функция Get-VMHostFirmwareVersion моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам узнать версию и дату выпуска Firmware ваших серверов ESXi. Для большей гибкости и удобства в использовании, функция написана в виде PowerShell-фильтра.
В новой книге Фрэнка на 300 страницах раскрываются следующие моменты, касающиеся производительности подсистемы хранения платформ виртуализации, построенной на базе локальных дисков хост-серверов:
Новая парадигма построения виртуального датацентра с точки зрения систем хранения
Архитектура решения FVP
Ускорение доступа к данным
Технология непрерывной доступности Fault Tolerance
Технология Flash
Техники доступа к памяти
Настройка кластера решения FVP
Сетевой дизайн инфраструктуры локальных хранилищ
Внедрение и пробная версия решения FVP
Дизайн инфраструктуры хранилищ
Несмотря на то, что книга рассматривает в качестве основного продукта решение FVP от компании PernixData, ее интересно читать и с точки зрения понимания архитектуры и производительности подобных решений.
Компания VMware выпустила интересную инфографику, наглядно представляющую распреление сертифицированных специалистов VMware Certified Professionals (VCP) по регионам мира. 70% стран мира имеют хотя бы одного VCP, а в 46% стран их больше, чем 50 (картинка кликабельна):
Интересно также и то, что 38% VCP имеют более, чем одну сертификацию (видимо, имеется в виду сертификация именно VMware).
Судя по всему, у нас VCP почти столько же, сколько, например, в ЮАР. Это прискорбно - посмотрите на Индию или Австралию, к примеру, и оцените разницу в масштабах.
Наверняка многие из вас знают, что представляет собой продукт VMware vRealize Operations 6.x (а некоторые и используют его в производственной среде), предназначенный для мониторинга производительности виртуальной инфраструктуры VMware vSphere, анализа ее состояния, планирования и решения проблем.
Добрые ребята с сайта vXpresss сделали уже готовый дэшборд для vRealize Operations, который включает в себя 15 объектов "Super Metrics", 6 представлений (Views) и один кастомизированный XML. Визуально дэшборд выглядит следующим образом (кликабельно):
То, что могло бы занять у вас часы настройки, теперь можно просто развернуть за 10 минут, используя готовый модуль.
Опишем эти представления:
1 - список ваших кластеров, которые вы мониторите через vRealize Operations Manager 6.x.
2 - этот виджет отображает ключевые метрики с точки зрения процессора, памяти и хранилищ датацентра.
3 - данный виджет показывает пиковые и средние значения использования CPU виртуальной машиной в выбранном кластере. Это позволяет видеть нагруженные машины в вашем окружении.
4 - этот виджет похож на предыдущий только здесь отображается метрика Contention% для CPU (ожидание ресурсов со стороны ВМ), которая является одной из ключевых в плане производительности.
5 - виджет показывает пиковые и средние значения использования памяти (Memory) виртуальной машиной в выбранном кластере. Это позволяет видеть тяжелые по памяти машины в вашем окружении.
6 - по аналогии с CPU Contention, для памяти используется метрика Memory Contention % - отображаются также ее средние и пиковые значения. Ее рост показывает, что ваши машины скоро будут конкурировать за ресурсы оперативной памяти (и начнется memory overcommitment).
7 - этот виджет показывает пиковые и средние значения IOPS для виртуальной машины в выбранном кластере.
8 - в дополнение к IOPS, здесь можно видеть пиковое и среднее значение задержки в дисковой подсистеме (Virtual Disk latency), которая возникает при работе виртуальных машин.
Скачать описанный дэшборд и его компоненты можно по этим ссылкам:
Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.
3 года назад мы писали об утилите ESXi5 Community Packaging Tools 2.0, которая позволяет создавать собственные пакеты для VMware ESXi в форматах VIB (VMware Installation Bundle) and ZIP (VMware Offline Bundle). В результате VIB-файлы получают уровень доверия (acceptance level) Community Supported. Зачастую, эти утилиты необходимы пользователям для включения сторонних драйверов устройств в состав дистрибутива платформы ESXi, которые отсутствуют в стандартном комплекте поставки.
На самом деле, изменений было сделано не так много, но они есть и важные:
Появилась полная поддержка VMware vSphere 6 (именно поэтому "ESXi5 Community Packaging Tools" (ESXi5-CPT) переименованы в "ESXi Community Packaging Tools" (ESXi-CPT).
Пакетный сценарий TGZ2VIB5.cmd обновлен до версии 2.3.
Пофикшено название уровня доверия (acceptance level) "certified" (раньше он назывался "vmware").
Добавлены пресеты конфигураций "ESXi 6.0+ driver" и "VMware Tools" (tools-light.vib). Теперь вы можете создать свой пакет VMware Tools для распространения в гостевых ОС на базе гипервизора ESXi!
Добавлена поддержка типа VIB-пакета (vibType) "locker".
Пакетный файл VIB2ZIP.cmd обновился до версии 1.3 - туда были добавлен выбор настроек совместимости для VMware ESXi.
Видео о создани VMware Offline Bundle с помощью VIB2ZIP:
Скачать ESXi Community Packaging Tools версии 2.3 можно по этой ссылке.
На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:
Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.
Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).
Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.
Как многие из вас знают, в состав платформы виртуализации VMware vSphere 6.0 входит виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.0, который реализует все необходимые сервисы управления виртуальной инфраструктурой в виде уже готовой виртуальной машины на базе Linux.
По умолчанию в данном модуле настроено устаревание пароля в 90 дней, и если в течение этого времени он не был сменен, он устареет и не будет работать. То есть, через три месяца вы увидите вот такую картинку:
Unable to authenticate user. Please try again.
В этом случае вам нужно либо сбросить пароль vCenter Server Appliance и установить новый, либо (если вы помните старый пароль , но он устарел) разлочить аккаунт.
Делается это вот каким образом:
1. Используем какой-нибудь Linux LiveCD (например, KNOPPIX).
Подключаем ISO-шку к виртуальной машине с vCSA и загружаемся с нее в Shell:
Затем повышаем привилегии командой:
# su -
2. Монтируем файловую систему vCSA с помощью команды:
# mount /dev/sda3 /mnt
3. Создаем резервную копию файла с паролем рута и открываем его для редактирования:
# cd /mnt/etc
#
cp shadow shadow.bak
# vi /mnt/etc/shadow
Видим определение пароля root:
4. Если вы помните пароль, а он просто устарел:
В этом случае просто удаляем букву x (выделена желтым) и цифру 1 (также желтая - останется два двоеточия). Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения.
После перезагрузки vCSA старый пароль root будет работать.
5. Если вы не помните пароль:
Надо заменить его хэш. Сначала смотрим, что стоит в начале строчки. У вас, скорее всего, будет там $6$, что означает, что это хэш, сгенерированный по алгоритму SHA512. От правого доллара конструкции $6$ и до следующего доллара в этой строчке идет так называемая "соль" - это значение вам надо записать на бумажке или сфотать (доллары в него не входят).
Далее генерируем новый пароль, используя записанную соль, следующей командой:
# mkpasswd -m sha-512 <новый пароль> <соль>
Потом получившийся пароль просто вставляем в файл /etc/shadow, который вы только что открывали. Вставляем его от правого доллара, ограничивающего соль, до первого двоеточия. Тут плоховато видно, но суть понятна, куда вставлять этот пароль:
После перезагрузки vCSA вы можете логиниться в него с новым паролем.
Есть такая штука в сфере ИБ - Security banner. Это когда при логине в какую-нибудь консоль вы выводите пользователю сообщение о характере информации и системы, к которой он пытается получить доступ, и предупреждаете о возможной ответственности за несанкционированный доступ. Вряд ли это много кого остановит, но все же с ним лучше, чем без него.
Вот способ сделать security banner для VMware ESXi. В VMware vSphere он бывает двух видов:
1. Login banner
Это текст, который показывается после ввода имени пользователя, но до ввода пароля:
Чтобы его поменять нужно залогиниться на хост VMware ESXi и с помощью редактора vi или nano отредактировать следующий файл:
# vi /etc/issue
Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения. Затем перезагрузите демон SSH следующей командой:
# /etc/init.d/SSH restart
2. Баннер MOTD.
Это баннер, который показывают пользователю после успешного логина по SSH. Чтобы задать его (по умолчанию он пустой), нужно отредактировать следующий файл через vi:
# vi /etc/motd
Также можно не лазить на хост VMware ESXi, а открыть vSphere Web Client, перейти в Manage->Settings и в разделе Advanced System Settings поискать по строчке "etc.". Там будет 2 параметра:
Config.Etc.issue - это текст для security banner
Config.Etc.motd - текст для баннера motd
То же самое можно сделать и в толстом клиенте vSphere Client:
Помните некоторое время назад мы писали о новой версии решения для виртуализации настольных ПК предприятия VMware Horizon View 6.1.1, в которую были добавлены такие полезные функции, как Client Drive Redirection и поддержка десктопов с ОС Linux?
На днях один из администраторов VMware Horizon опубликовал диаграмму портов и соединений этого решения, так как оно за последние годы значительно разрослось и требует некоторой настройки нужных правил на корпоративных сетевых экранах.
Собственно, кликабельная диаграмма:
Основные рекомендации по настройке фаерволов для VMware Horizon View:
TCP/UDP 4173: PCoIP-порт, используемый для хостов RDS.
TCP 4002: порт режима JMS enhanced security mode (SSL).
TCP 5443: слушающий порт для протокола Blast для прямых соединений с Linux-десктопами (требует наличия Horizon Client версии 3.3 или более поздней).
TCP 8443: слушающий порт для протокола Blast для соединений с Linux-десктопами через Blast Secure Gateway (требует наличия Horizon Client версии 3.3 или более поздней).
TCP 8472: интерфейс коммуникации между кластерами View в архитектуре Cloud Pod (interpod API).
TCP 22389: коммуникация Global ADLDS (также для Cloud Pod).
HTTPS (443): доступ для Horizon Client - аутентификация и RDP-туннель (HTTPS Secure Gateway).
HTTPS (8443): используется для HTML 5 доступа к виртуальным ПК Linux. HTML-доступ к ПК с ОС Linux официально не поддерживается, хотя большинство браузеров работают.
HTTPS (22443): HTML-доступ по протоколу Blast для виртуальных ПК с ОС Windows.
TCP 9427: используется механизмами Windows Multimedia Redirection (MMR) и Client Drive Redirection (CDR).
ESP Protocol (порт 50): используется для серверов Security Server и Connection Server при защищенной коммуникации IPSEC (требует включенного Windows firewall с опцией Advanced Security).
UDP 500: коммуникация IPsec для Security Server и Connection Server при создании пары.
В нескольких заметках мы освещали новости о продукте VMware Log Insight, который предназначен для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска.
Многие администраторы VMware vSphere знают, что такой продукт есть, на мало кто знает, зачем он реально нужен. Ну да, централизованно собирает логи, есть аналитика, но когда он может пригодиться? Поэтому приведем тут пример решения конкретной административной задачи с помощью VMware Log Insight, которую описал у себя в блоге Iwan Rahabok.
Итак, каждый из вас, я надеюсь, знает, что снапшоты виртуальных машин - это плохо (назовем их "snapshits"). Поэтому в большой инфраструктуре часто оказывается необходимым найти тех, кто снапшоты создает, а если он потом их удалил, то когда это было сделано.
Для начала создадим и удалим снапшот виртуальной машины. Это отобразится в списке последних задач vSphere Web Client:
Откроем консоль VMware Log Insight и перейдем в представление "Virtual Machine – Snapshots", как показано ниже:
Видим, что оба события были пойманы. Переключимся в представление Interactive Analytics (в верхнем меню):
Тут мы видим оба события на таймлайне. Расширим диапазон до 7 дней и добавим фильтр по строчкам "vmw_esxi_snapshot_operation". Видим записи лога о снапшотах:
Ну и переключимся на вкладку Field Table, где выберем параметр vc_username в качестве фильтра (если пользователь заходил из vCenter):
Ну и видим тут, что всеми этими делами занимался пользователь obi-wan.
На самом деле, с помощью Log Insight можно вытягивать очень много чего полезного, например, можно было бы составить фильтр так, чтобы показать виртуальные машины только по указанному шаблону именования.
Некоторое время назад мы писали про обработку гипервизором VMware vSphere таких состояний хранилища ВМ, как APD (All Paths Down) и PDL (Permanent Device Loss). Вкратце: APD - это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды, а PDL - это когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось.
Так вот, в новой версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эти ситуации со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без "хост-хозяина".
Для того чтобы это начало работать, нужно на уровне кластера включить настройку "Protect against Storage Connectivity Loss":
Далее посмотрим на настройки механизма Virtual Machine Monitoring, куда входят и настройки VM Component Protection (VMCP):
С ситуацией PDL все понятно - хост больше не имеет доступа к виртуальной машине, и массив знает об этом, то есть вернул серверу ESXi соответствующий статус - в этом случае разумно выключить процесс машины на данном хосте и запустить ВМ на других серверах. Тут выполняется действие, указанное в поле Response for a Datastore with Permanent Device Loss (PDL).
Со статусом же APD все происходит несколько иначе. Поскольку в этом состоянии мы не знаем пропал ли доступ к хранилищу ВМ ненадолго или же навсегда, происходит все следующим образом:
возникает пауза до 140 секунд, во время которой хост пытается восстановить соединение с хранилищем
если связь не восстановлена, хост помечает датастор как недоступный по причине APD Timout
далее VMware HA включает счетчик времени, который длится ровно столько, сколько указано в поле Delay for VM failover for APD (по умолчанию - 3 минуты)
по истечении этого времени начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect)
У такого механизма работы есть следующие особенности:
VMCP не поддерживает датасторы Virtual SAN - они будут просто игнорироваться.
VMCP не поддерживает Fault Tolerance. Машины, защищенные этой технологией, будут получать перекрывающую настройку не использовать VMCP.
Как мы видим, за 7 лет размер вырос не катастрофически - всего в три раза. Посмотрите на продукты других вендоров и поймете, что это не так уж и много.
На диаграмме:
Как автор вычислял размер гипервизора? Он сравнил размер следующих пакетов, содержащих в себе компоненты ESXi:
Пакет "image" в ESXi 3.5
Пакет "firmware" в ESXi 4.x
VIB-пакет "esx-base" в ESXi 5.x и 6.x
Табличка размеров гипервизора для всех версий (не только мажорных):
ESXi
Size
4.0
57,80 MB
4.0 U1
58,82 MB
4.0 U2
59,11 MB
4.0 U3
59,72 MB
4.0 U4
59,97 MB
4.0 LATEST
59,99 MB
4.1
85,45 MB
4.1 U1
85,89 MB
4.1 U2
85,25 MB
4.1 U3
85,27 MB
4.1 LATEST
85,19 MB
5.0
133,64 MB
5.0 U1
132,32 MB
5.0 U2
132,27 MB
5.0 U3
132,56 MB
5.0 LATEST
132,75 MB
5.1
124,60 MB
5.1 U1
124,88 MB
5.1 U2
125,67 MB
5.1 U3
125,85 MB
5.1 LATEST
125,85 MB
5.5
151,52 MB
5.5 U1
152,24 MB
5.5 U2
151,71 MB
5.5 LATEST
151,98 MB
6.0
154,90 MB
Но почему ISO-образ ESXi 6.0 занимает 344 МБ, а не 155 МБ? Потому что есть еще пакет VMware Tools для различных гостевых ОС (а их поддерживается очень много) плюс драйверы устройств серверов.
До VMworld еще 7 месяцев и сейчас в сфере виртуализации межсезонье. Поэтому 15 апреля компания VMware решила провести бесплатное онлайн-мероприятие VMware Online Technology Forum, принять участие в котором может любой желающий.
На форуме будут следующие активности:
Прямой эфир с техническими экспертами VMware, где можно будет задавать вопросы онлайн. На ивенте будут такие знаменитости, как Joe Baguley, Duncan Epping и Mike Laverick.
Множество лабораторных работ и лекций по следующим темам:
Как вы знаете, недавно вышла новая версия платформы виртуализации VMware vSphere 6.0, для которой было также обновлено средство создания кластеров хранилищ VMware Virtual SAN 6.0 на базе локальных дисков серверов. Среди прочих новых возможностей VSAN, было сказано об улучшении производительности решения, что и решили проверить коллеги на тестах вот тут.
Тест проводился дома и не претендует на какую-либо достоверность, но, все же, его весьма интересно посмотреть. Автор взял 3 узла Shuttle SZ87R6 следующей конфигурации (надо отметить, что они не в HCL):
Для тестирования были использованы следующие гипервизоры:
ESXi 5.5 Update 2 (build 2068190)
ESXi 6.0 (build 2494585)
В качестве средства создания нагрузки взяли IOmeter, размещенный в виртуальной машине с двумя vCPU, 4 ГБ памяти и Windows Server 2012 в качестве гостевой ОС. Было также сконфигурировано 2 дополнительных виртуальных диска на контроллере PVSCSI:
Для IOmeter было создано три профиля нагрузки, размер Working Set - 100 МБ (204800 секторов). Малый размер Working Set был выбран для более быстрого прогрева кэша.
Profile 1
Profile 2
Profile 3
Worker 1
vDisk 1
vDisk 1
vDisk 1
Sectors
204800
204800
204800
Outst. IO
16
16
16
Worker 2
vDisk 2
vDisk 2
vDisk 2
Sectors
204800
204800
204800
Outst. IO
16
16
16
Read
100%
0%
65%
Write
0%
100%
35%
Random
100%
100%
60%
Sequential
0%
0%
40%
Block size
4 KB
4 KB
4 KB
Alignment
4096 B
4096 B
4096 B
Результаты (кликабельно):
Как мы видим, VSAN 6.0 показал себя лучше при всех типах нагрузки - выжимает больше IOPS и имеет меньшую задержку (latency), а именно:
VSAN 5.5 (он же 1.0) использует формат vmfsSparse, который, по-сути, является redo-логом. В версии VSAN 6.0 появился новый формат снапшота vsanSparse, который использует механизм redirect-on-write (подробнее тут).
Тест проводился просто - запустили IOmeter (профиль 3) и последовательно снимали снапшоты, наблюдая производительность с помощью VSAN Observer.
Светло-серые картинки - это VSAN 1.0 (5.5), а темно-серые - VSAN 6.0 (кликабельно). Обратите внимание, что значения по осям X и Y на картинках не всегда соответствуют.
Итак, Latency:
Кстати, временами по latency VSAN 6.0 хуже своей предыдущей версии.
По IOPS результаты интереснее:
При создании нагрузки в виде снапшотов VSAN 6.0 снижает производительность по IOPS на 8%, а вот предыдущая версия VSAN - на 49%. Преимущества нового формата очевидны.
Полоса пропускания (Bandwidth):
Интересный эффект - в VSAN 1.0 существенно увеличивается трафик на чтение после снятия каждого снапшота, при этом у VSAN 6.0 такого не происходит. Еще одно улучшение Virtual SAN 6.0.
В целом можно отметить, что производительность кластеров VSAN заметно возрасла, ну а оптимизация снапшотов улучшит и производительность процессов, использующих эту технологию (например, резервное копирование).
Не так давно мы писали о новых возможностях решения для отказоустойчивости хранилищ VMware Virtual SAN 6.0, которое выйдет вместе с новой версией платформы виртуализации VMware vSphere 6. Одной из таких новых возможностей стал режим All-Flash Configuration, когда хост-сервер ESXi использует только SSD-накопители. При этом быстрые и надежные накопители используются для целей кэширования (cache tier), а устройства попроще - для хранения данных (capacity tier).
Чтобы использовать конфигурацию All-Flash нужно специальным образом пометить диски хост-серверов ESXi для яруса Capacity Tier. Сделать это можно через консоль RVC, либо через интерфейс ESXCLI на каждом из хостов.
Так, например, это делается через RVC:
А вот последовательность команд ESXCLI:
Получается, что на каждом из хостов кластера Virtual SAN администратор должен с помощью CLI-интерфейса обозначать диски, которые будут использоваться для создания яруса хранения виртуальных машин. Жутко неудобно.
Кстати, узнать о том, входит ли конкретный диск в Capacity Tier можно с помощью команды VSAN Disk Query (vdq):
# vdq -q
Так вот, коллеги с punchingclouds.com делают утилиту с GUI, которая позволит назначать дисковым устройствам на хостах ESXi это свойство быстро и удобно, экономя часы времени (представьте, что у вас 64 узла в кластере, на каждом из которых по 10 SSD-дисков, то есть надо назначить 640 дисков!).
Для начала работы надо ввести данные учетной записи VMware vCenter, а также пользователя на хостах VMware ESXi. Минус тут в том, что пароль на всех хостах должен быть одинаковый (но это обещают исправить в следующей версии, сделав загрузку csv-файла с паролями).
Перед тем, как приступить к операциям с дисками, нужно включить SSH на хостах ESXi (настройка на хостах происходит через ESXCLI), делается это кнопкой "Enable SSH". Далее можно сгруппировать похожие устройства по хостам или кластеру, после чего отметить нужные устройства в списке дисков.
Ну и далее нажимаем кнопку "Set Capacity Flash", чтобы назначить диски для хранения виртуальных машин, или "Remove Capacity Flash", чтобы отвязать их от этой роли.
Утилита VMware VSAN All-Flash Configuration Utility скоро будет доступна, следите за обновлениями здесь.
Как вы знаете, после запуска виртуальной машины на платформе VMware vSphere, в папке с машиной создается файл *.vswp, который предназначен для свопирования памяти ВМ в критической ситуации. Если у машины проявляется нехватка памяти на хосте VMware ESXi, и она не получает ее через механизм Memory Ballooning, то страницы памяти начинают сбрасываться в этот vswp-файл. Это самая плохая ситуация, так как структурная организация этого файла и то, как понимает своп операционная система, две большие разницы, а значит скорость работы существенно замедляется не только из-за того, что работа идет с диском вместо RAM, но еще и уходит время на поиск нужных страниц.
Соответственно, если у машины 4 ГБ оперативной памяти, то размер vswp-файла также 4 ГБ:
Если мы меняем Memory Reservation для виртуальной машины, то ее файл подкачки уменьшается на величину этого резерва - так как физическая память закрепляется за машиной и не возникнет условий, когда эту часть потребуется свопировать.
Но если сделать Memory Reservation для работающей ВМ (в данном случае 2 ГБ), то размер файла подкачки останется прежним:
Для того, чтобы vswp-файл уменьшился на величину Memory Reservation, надо перезагрузить ВМ - тогда он станет размером 2 ГБ:
Напомним, что у выключенной машины vswp-файла нет.
Но что если у включенной машины убрать (или изменить) Memory Reservation? Все просто - он автоматически увеличится до размера незарезервированной памяти ВМ. Убираем резерв в 2 ГБ и файл вырастает до 4 ГБ:
Ну и напомним формулу:
Swap (.vswp) file size = VM Configured Memory – VM reserved memory
В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.
Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.
К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.
Тут основная рекомендация - держать машины с ролями MBX / MSRна одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).
В этой части цикла описываются рекомендуемые настройки механизма VMware HA.
В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.
Многие администраторы устанавливают VMware Tools с помощью vSphere Client, который предоставляет идущую в дистрибутиве версию этого пакета. Однако не все знают, что VMware Tools можно скачать по прямой ссылке из репозитория VMware, затем положить exe-файл на файловый сервер (если у вас гостевая ОС Windows) и запускать на всех виртуальных машинах.
Последняя версия тулзов всегда находится по этой ссылке:
Но эти пакеты доступны только для следующих версий гостевых ОС:
Community ENTerprise Operating System (CentOS) - версии с 4.0 по 6.x
Red Hat Enterprise Linux версии с 3.0 по 6.x
SUSE Linux Enterprise Server версии 9 по 11
SUSE Linux Enterprise Desktop версии 10 по 11
Ubuntu Linux версии с 8.04 по 12.04
Надо отметить, что доступные в репозитории пакеты содержат компоненты VMware Tools, начиная еще с версий ESX 3.5. Но с версии vSphere 4.1 все они стали обратно совместимы - вы можете скачать последнее обновление VMware Tools и накатить его на любую версию vSphere 4.x или 5.x.
Кроме того, если в списке остутствуют необходимые ОС Linux, то можно воспользоваться пакетом Open VM Tools, которые являются открытой версией VMware Tools и рекомендованы к распространению вендорами платформ. Например, вот тут указано, как нужно ставить Open VM Tools в гостевых ОС RHEL 7.
Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.
Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).
Далее заходим на свой хост ESXi по SSH и выполняем команду:
esxcli vm process list
Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.
Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):
esxcli vm process kill -t force -w WorldID
Выглядит это примерно вот так:
Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.
Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:
vim-cmd vmsvc/getallvms
Если помните часть имени ВМ, можно искать с помощью grep:
vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>
Найдя VMID, проверяем дополнительно, что она выключена:
vim-cmd vmsvc/power.getstate <vmid>
Теперь включаем виртуальную машину:
vim-cmd vmsvc/power.on <vmid>
Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.
Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).
В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.
Итак, чтобы отключить vMotion для конкретной виртуальной машины, нужно создать новую роль (No-vMotion), для которой необходимо отключить привилегию по vMotion машины, назначатить эту роль администраторам и добавить пермиссию для виртуальной машины, указав юзеров с этой ролью (как работает этот механизм читайте здесь).
Итак, добавляем роль No-vMotion в vSphere Web Client:
1. Заходим в vCenter как administrator.
2.
Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,
Migrate powered off virtual machine
Migrate powered on virtual machine
Query vMotion
Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:
1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".
Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):
Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:
Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:
Как многие из вас знают, бета-версии платформы виртуализации VMware vSphere всегда были закрытыми, тестировал их очень ограниченный круг пользователей, находившихся под действием соглашения NDA (Non-disclosure agreement), которое подразумевало страшные кары и звонки юристов в случае его нарушения. В письмах с новостями о бета-версии были большие красные буквы про конфиденциальность, а за разглашение информации о новых возможностях продукта пытались наказать всех подряд, даже тех, кто этого соглашения не подписывал.
Возможно, компании VMware надоела вся эта канитель, и она впервые в своей истории решилась на открытое бета-тестирование VMware vSphere 6.0, но (видимо, по привычке) решила запретить публичное разглашение и обсуждение сведений о новой версии продукта.
For the first time, and unlike previous beta cycles for vSphere, this vSphere Beta is open to everyone to sign up and allows participants to help define the direction of the world’s most widely adopted, trusted, and robust virtualization platform.
Зарегистрировавшись в публичной бета-программе и подписав NDA, пользователи попадают в закрытое общество, где они могут обсуждать новые возможности платформы VMware vSphere, но им как бы запрещено это обсуждать с теми, кто не принимает участие в бете. Звучит как что-то очень параноидальное, но это так.
Итак, как участник VMware vSphere Beta Program вы можете:
Обсуждать продукт и саму программу с другими участниками бета-программы.
Постить в закрытые форумы на VMware Communities.
Общаться с вендорами серверного оборудования на эту тему (они тоже должны быть под NDA).
В то же время как участник VMware vSphere Beta Program вы не можете:
Обсуждать условия программы или новые возможности продукта публично.
Обсуждать программу приватно, но с теми людьми, которые не находятся под NDA.
В общем, можете сами теперь попробовать, что такое VMware vSphere 6.0 Beta 2. Нужно нажать кнопку "Join now!" в правой части, после чего принять VMware Master Software Beta Test Agreement (MSBTA) и vSphere Program Rules agreement. Бесспорно, публичная бета-кампания позволит VMware поднять качество своих продуктов, так как любой желающий сможет сообщить об ошибке, возникшей у него в тестовой среде.
Одновременно с анонсом публичной беты VMware vSphere 6.0 компания VMware раскрыла некоторые подробности о функциональности Virtual Volumes (VVols), о которой мы писали вот тут. Концепция VVol (она же VM Volumes) увеличивает уровень гранулярности работы хост-сервера с хранилищем за счет непосредственных операций с виртуальной машиной, минуя сущности "LUN->том VMFS->Datastore". Тома VVol является неким аналогом существующих сегодня LUN, но с меньшим уровнем гранулярности операций по сравнению с томами VMFS (последние, как правило, создаются из одного LUN).
То есть, VVol - это низкоуровневое хранилище одной виртуальной машины, с которым будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Делается это через механизм vSphere APIs for Storage Awareness (VASA). Таким образом, все необходимое хранилище виртуальной машины упаковывается в этот самый VVol. Более подробно о томах VVol можно узнать на специальной странице.
Само собой, такое должно поддерживаться со стороны производителей хранилищ, которые уже давно работают с VVol и записали несколько демок:
Tintri
SolidFire
HP
NetApp
EMC
Nimble Storage
Ну а вообще, конечно, это шаг вперед по сравнению с той паранойей VMware, которая была раньше вокруг бета-версий VMware vSphere.
RSS
